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edgment of messages, and conferencing, whisper and talk 
modes. The system can be implemented in any Internet- 
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tained by the server. The server records in the data repository 
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between and requests issued by system users, and handles 
the communications and requests cooperatively with the 
client application in accordance with the system mode being 
exercised (e.g., talk, conferencing, whisper, mail, 
messaging, open display, private bulletin boards, etc.). In an 
embodiment where the server and client appHcations are 
web based, the server application sends all information to 
the client apphcation in the form of web pages, which the 
user of the client can view and respond to using a browser. 
For example, when implementing open display, the server 
application formats the messages sent to a user so that the 
messages* contents are directly displayed on a bulletin board 
along with threading information. As another example, when 
implementing private bulletin boards, the server application 
creates private message boards for each user that allow each 
user to access only those messages in which he participates 
(as sender or recipient). When a user acknowledges a 
message, the server application closes the thread including 
the message and permits no additional activity in that thread. 
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□ 10-16-97 14:32 To:Arlene From: Mit CC: Ulysses 

• Re: 145 Piccadilly 

• Pis order 3R reporf on 145 Rccadllly and give copy to Agnes. 

O 10-17-97 9:24 To: Mit FrDm:Arlene CC: 
Re: 145 Piccadilly 

3R report ordered, will give copy to Agnes upon receipt 



442 
420-1 



oAck: 10-17 12:45 
444-/ 



□ 10-20-97 10:47 To:Arlene From: Mit CC: 
Re: 233-G Boardwalk 

Call sellers for copy of TDS and Supp. TDS on 233-G Boardwalk. 



420-2 



O 1Q-20-S7 16:10 To: Mit From:Arlene CC: oAck; 10-21 8:42 
Re: 233-G Boardwalk 

Sellers on Boardwalk will have TDS & Supp ready by tmo. do you want to 
order smoke detector inspection? 420-3 

o 10-21-97 8:42 To:Artene From: Mit CC: oAck: 
Re: 233-G Boardwalk . 
No need. Ttiis one's exempt from smoke detection 
inspection. 

□ 10-20-97 12:15 To: Agnes From: Mit CC: 
Re: 145 Piccadillv 

Order payoffe on 145 PiccadiDy, PCOE on Nov. 11th. 

□ 10-20-97 15:10 To: Mit FromrAriene CC: 
Re: 410 Boardwalk #3 

I need copies of Listing Agreement, TDS, Disclosures, etc. on 410 Boardwalk #3 
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□ 10-16-97 14:32 ToiAriene From: Mit CC:Ulv5ses 442A- 
Re: 145 Piccadilly 

Pis order 3R report on 145 Piccadilly and give copy to Agnes. 420-1 

A 



o 10-17-97 9:24 To: Mil From:Arlene CC 
Re: 145 Piccadilly 
3R report ordered. Wil 



oAck: 10-17 12:45 
ill give copy to Agnes upon receipt. 444A-^ 
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□ 10-17-97 9:30 To: Agnes From:ArIene CC: oAck: 10-18 8:10 
Re: 145 Piccadilly 

Have ordered 3R report. Will fonvard to you upon receipt 

O 19-19-97 9:19 TQjAri^ng Frpm:Agn?? gC; oAck: 10-18 9:45 
Re: 145 Piccadilly 

Just let me know when you have 3R in hand. I'll come pick it up. 

□ iq;20-97 mi TQ:Ari 9n^ FrQfn; Mit QC i 
Re: 233-G Boardwalk 

Call sellers for copy of TDS and Supp. TDS on 233-G Boardwalk. 

O 10-20-97 16:10 To: Mit FromiArlene CC: ©Ack: 10-20 18:20 
Re: 233-G Boardwalk 

Sellers on Boardwalk will have TDS and Supp ready by tmo. do you want to 
order smoke detector inspection? 



o 10-20-97 18:20 TQ:Ari6ne From: Mit CC: oAck: 
Re: 233-G Boardwalk 

No need. This one's exempt from smoke detection inspection. 

□ 10-20-97 14:35 To: Arlene From: Ulysses CC: 
Re: 45 Menio 

Change Listing Price on 45 Menio to $205,000 and update MLS. 

□ 10-20-97 14:47 To: Arlene From:Ulvsses CC: 
Re: 145 Northwood 

Extend Listing Expiration Date to February 28, 1998 on 145 Northwood 

□ 10-20-97 15:10 To: Mit From: Arlene CC: 
Re: 410 Boardwalk #3 

I need copies of Listing Agreement. TDS, Disclosures, etc. on 410 Boardwalk #3 
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copies of same to the lender when I get them back. 

Aio^° 1^04-97 16:14 Ta:Arlene From:Mit CC: oAck: 10-S97 8:43 
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Payoffs ordered. Should be at title company within 5 bus. days per Lender. 
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Type (Open or Private) 
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Server application: 
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Notify all Participants, 
Allow Moderator to administer 
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740- 
722- 

724- 
726- 

728- 
730- 

732- 
734- 

736- 
738- 



Z 



Mit's Message Board 



Current messages: 43 1 0-21 -97 Open messages: 25 

/-742 

□ 10-21-97 13:29 To: ALL From: Ulvsses CC: W44 
-Re: OPEN CONFERENCE NOTIFICATION - ROOM 1258 - NOW-*/ 
Affects of new Health Ins Benefits; NOW IN PROGRESS. 

^746 ^748 

□ 10-21-97 13:01 To: ALL From: Agnes CC: 
Re: ANNOUNCEMENT 

Don't forget about the Picnic tomorTow! See you all there, promptly @ 10AMI 

□ 10-21-97 12:14 To: Mit From: Arlene CC: 

Re: PRIVATE CONFERENCE NOTIFICATION - ROOM 3422 ■ NOW 
Company Policy Review, NOW IN PROGRESS. 

a 10-21-97 00:01 To: ALL From: Dave CC: 

Re: OPEN CONFERENCE NOTIFICATION - ROOM 5557 - TODAY 

Improving Cust. Relations; 10-21 @ 14:00. 

o 10-20-97 13:01 To: Mit From:Marcia CC: 
Re: ANNOUNCEMENT 

Surprise Birthday Party for Emily tonight, 8PM, at my place. Be prompL' 

o 10-20-97 9:47 To: Mit From: Ariene CC: 

Re: PRIVATE CONFERENCE NOTIFICATION - ROOM 61 51 - FUTURE 750 

Company Christmas Party; 10-28 @ 15:00. ^ 

O 10-20-97 10:24 To: Arlene From:I\1it CC: oAck: 10-20 12:44 
Re: PRIVATE CONFERENCE NOTIFICATION - ROOH^OT 
Will Attend. 

□ 10-19-97 12:17 To: Ulysses From: Mit CC: 

Re: PRIVATE CONFERENCE NOTIFICATION - ROOM 3118 - FUTURE 
Long Range Business Plan; 10-29 % 13:00. 

O 10-20-97 10:34 To: Mit From: Ulysses CC: oAck: 10-20 11:17 
Re: PRIVATE CONFERENCE NOTIFICATION - ROOM 31 18 
Cannot Attend. 



FIG. 78 
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CONFERENCE MODE IMPLEMENTATION 770 

. ^ 



Display Board 



772 



CONFERENCE SESSION 
ROOM 6151 
10-28-97 



Topic: Company Christmas Party 



Moderator: Arlene 



XYZCorp. 
Company Christmas Party 
AGENDA 

Logistics 

A. Setup 

B. Registration 

C. Entertainment 

Finances 

A. Band vs. DJ 

B. Dinner Costs 

C. Santa Rental 

D. Gift Exchange 



PRINT 



HIDE 



MODIFY 



SEND 



Comment Screen 



774 



Participants 



776 



Fmi: Arlene - I think we should ask Larry to play Santa again. 

He did such a good job last year. The kids loved 
him! 

Frm: Mit - Yes. I agree. Agnes, can you give him a call and 

ask him if he's available on Dec 19tfi? 
»>Ulysses has joined the session <« 
Fmi: Agnes - Okay, I'll call him tomonrow. What about caterers? 
Fmi: Anene - Nico' did a wonderful job for our Appreciation Party 

last month; I think we should use him again! 
Fmn: Ulysses - Hey, everyone. Sorry I'm late. Came from a tong meeting. 
Fnn: Mit - Glad you can join us, Uly! we need your input. 
»>Sammy has left the session.«< 
Fmn: Arlene - Uly, I posted an agenda on the board for evoyone 
to see. We're on #2 right now. Well, kinda. 



Ariene 




Agnes 




m 

Ulysses 




Sammy 




David 




Alice 




Nicolas 




Isabel 




Larry 









] I SEND I [Y] [N] ["ANON 
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CHANGE 




PRINT 
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MINUTES 
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TALK MODE IMPLEMENTATION 800 

^ 



802 



TALK SESSION 
Dialogue Input Screen 



To: 



Mit 



804 



Directory 



Hey, Mil Did you hear the rumor about the Christmas Party? 



6 



0 



806 



Send 




Clear 




Cancel 



FIG. 8A 
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TALK MODE IMPLEMENTATION 820 



z 



824- 
826 



822 



TALK SESSION 
Arlene's Dialogue Screen 



• Frm: Arlene - Hey, Mil Did you hear the rumor about 
the Christmas Party? 



■Frm: Mit- 



830 



What rumor did you hear? Tell me what 
you heard, and I'll tell you what i heard! 



Send 



Cancel 



FIG. 8B 
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MAIL MODE IMPLEMENTATION 



910- 



904 



Folder Personal/misc 



Mit's Mail Folder 
10-27-97 



eMail Account: mitmaur 




Mail You've Received: 47 9-12 
Date/Time Subject ^ 



Sender 



Size 



-H 10-27 1:16Pz 

906a -^g, 

■El 10-27 11:43A 

908a -^g, 

ISI 10-27 8:15A 

10-26 5:36P 
910a 

H 10-26 3:27P 
B 10-26 3:05P 



Toastmastei's Meefana 
10-29 12:55P 2K 
Looking for property to buy 
10-29 1:16P 6K 
New pricing schedule 
Company Hiring Policy Review 
10-26 8:37A 4K 
Revise Monthly Statement 
1998 Company Picnic 



DVaughn@d4tm.org 23K 



tomthumb@aol.com 



2K 



HYoung@cneLcom 18K 
amy_v^ang@polka.com 34K 



Mall You've Sent 
Date/Time 



22 

Subject 



WBlll@cnet.com 
HLee@webtv.com 

To 



18K 
22K 

Size 



® i 


p 10-27 1:16P Neu;s about Maaoie 


Ross@Bayinsider.com 


6K 




m 


I 


1 10-27 12:31P Calendar Orders will be delaved... 


Benas@work4u.com 


11K 






I 


1 10-2611:19A Mom'sCookina 


minortom@aol.com 


3K 




m 


® I 


1 10-25 3fl9P Cool Web Sites! Found 


BiilyGates@msn.com 


38K 




m 


® i 


P 10-2112i)6P Vacation Plans 


MNubla@kron.com 


12K 




m 


® I 


] 10-16 723A OcerafinQ Committee Meeting 


DVaughn@d4tm.org 


22K 








P 10-16 8:1 2A Reader's Dloest article about the.. 


. HJHughes@ccnet.com 


5K 




m 


i 


] 10-12 1:09P Uaricetino Presentations 


CFIgueroa@webtv.com 


29K 




[H] 



Move Groups Sort Folder 



Edit Folder 



Cancel 



Check Other Folder 



Check Other Account 
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02/04/2004, EAST Version: 1,4.1 



us 6,484,196 Bl 



INTERNET MESSAGING SYSTEM AND 
METHOD FOR USE IN COMPUTER 
NETWORKS 

The present invention relates generally to electronic 5 
coaimunication systems for use in computer networks and, 
particularly, to bulletin boards, instant messaging systems, 
electronic mail and chat rooms. 



BACKGROUND OF THE INVENTION 



10 



An electronic communication system for use in enterprise 
and other collaborative environments would ideally include 
a suite of capabilities that facilitate decision making and 
communication by two or more individuals. Such capabili- 
ties could include: i5 
enabling users to view the history of multiple conversa- 
tions with multiple parties (referred to hereinafter as 
"conversation history*'); 
enabling users to view messages as soon as they are 
available without requiring the users to log onto a 20 
public bulletin board system (BBS) (referred to here- 
inafter as "instant access"); 
enabling users to view the content of messages without 
requiring that the messages first be selected (referred to 
hereinafter as "open display"); 
enabling users to conduct their conversations in privacy 
so that each user is the only person who can view the 
history and content of their respective multiple conver- 
sations (referred to hereinafter as "private 
conversations"); 
enabling users to undeniably agree to proposals made in 
the course of a conversation in such a way that the 
conversation is concluded (referred to hereinafter as 
"agreement"); and 
enabling users to participate in moderated conferences or 
informal chats, as well as in conversations (referred to 
hereinafter as "integrated modes"). 
Prior art electronic systems, which include electronic mail 
(e-mail), bulletin board systems (BBS), instant messaging ^ 
and chat rooms, ofiFer some but not all of these capabilities 
and, as a result, are less then ideally suited to enterprise 
communications. The capabiUties of these various commu- 
nication systems are presented in Table 1. 



TABLE 1 





Conver- 






Private 








sation 


Instant 


Open 


Conver- 




Integrated 


System 


History 


Access 


Display 


sations 


Agree't 


Modes 


E-mail 


No 


Yes 


No 


Yes 


No 


No 


BBS 


Yes 


No 


No 


No 


No 


No 


Instant 


No 


Yes 


Yes 


Yes 


No 


No 


Messaging 














Chat 


No 


Yes 


Yes 


No 


No 


No 



45 



50 



55 



Referring to Tabic 1, e-mail systenas offer instant access 
to messages, but the messages must be selected and opened 
by the recipient (typically with a mouse ctick) to be viewed. 
E-mail messages are private as they are directed to specific 
recipients (one or many). No viewable history is available 60 
for E-mail messages except for the most rudimentary kind 
wherein a message being replied to can be copied into the 
body of the response. E-mail has only one mode and 
includes no feature whereby an e-mail user can issue a 
formal agreement to a proposal contained in a message, 65 
other than so stating in a reply message; e.g., "I agree to your 
proposal of Dec. 10, 1997 on the subject of contract terms." 



Like e-mail systems, bulletin board systems (BBS) do not 
provide open display, agreement, or integrated mode capa- 
bifities. Unlike E-mail systems, BBS display messages in a 
threaded format wherein a topic is listed first and all mes- 
sages germane to that topic are listed below the topic with 
different levels of indentation indicating historical and logi- 
cal relationships between the related messages. For example, 
a BBS might display a topic and two messages on the topic, 
the first having an associated comment, as follows: 
Topic: Discussion of X 
Message 1 

Comment on Message 1 
Message 2 

Because BBS do not provide open display, a user must select 
a message or comment to read that message or comment. 
BBS are centralized systems, meaning that a user must 
actually log in to the BBS to view topics and messages. As 
a result, messages are not immediately accessible (i.e., to 
read messages on a topic of interest a user must first access 
the BBS). Also, BBS are anything but private; typically, the 
same bulletin board is available to aU users, meaning that all 
messages are accessible to all users. 

Instant messaging systems allow users to communicate 
privately in real time over a network connection. An 
example of such a system is America On Line's "Instant 
Messages" feature, which allows an AOL member who is 
online to communicate with another member who is also 
online at the same time. Messages are openly displayed (i.e., 
without needing to be selected first). Thus, instant messag- 
ing systems provide private conversations, immediate access 
and open display capabilities. However, instant messaging 
systems do not support conversation history, agreement or 
integrated modes. Moreover, instant messaging systems are 
for one-on-one communication only. 

Chat systems allow a group of users to enter a chat room 
and then engage in a group conversation. The group con- 
versation can be moderated or un-moderated. Like instant 
messaging, chat systems are for informal communications 
and do not provide conversation history, agreement or 
integrated modes. Also like instant messaging, chat systems 
openly display all messages. However, chat messages are 
not immediately accessible as a user needs to enter a chat 
room before they can view messages. Also, chat rooms are 
not private as anyone in the chat room can read all chat 
messages typed by users in that room. 

Consequently, there is a need for an enterprise commu- 
nication system that provides features and/or combinations 
of features not present in prior art electronic communication 
systems. 

SUMMARY OF THE INVENTION 

In summary, the present invention is a electronic com- 
munication system that provides features and/or combina- 
tions of features not present in prior art electronic commu- 
nication systems. In particular, the present invention is a 
communication board system with multiple modes in which 
the communication board system can be variously config- 
ured as: 

a threaded instant message system (conversation history 
plus instant access capabilities); 

an open display biJletin board system (conversation- 
history plus open display capabilities); 

private message boards (conversation history plus private 
conversations capabilities); 

a system allowing message locking (conversation history 
plus agreement capabilities); and 
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a threaded mail system. implemented cooperatively by the client and server appli- 

The preferred embodiment of the system is implemented cations in the same manner as the message send feature, 

as a client server system including a server application, a Message acknowledge is a feature of the present invention 

client application and a data repository resident on the wherein a conversation's thread is closed, indicating that the 

server. In the preferred embodiment a sender requests com- 5 conversation has been concluded, typically with some agree- 

municatioo services using his client application, which ^or example, a user can indicate final acceptance of 

relays the request to the server program. The server program ^^^^ set out in the last of several threaded messages 

updates the data repository to reflect the request and then acknowledgiDg that message. The client application 

issues an appropriate message to the client appUcation of '^^^y^ acknowledge information to the server 

one or more recipients, depending on the requested com- lO ^^PPl^cation^ which updat^ the data repository by settmg the 

. ^. . . ... message status to ackcd and closmg the correspondmg 

mumcaUoD services Any response by a recipient .s coop- ^^^ad tt,„,^ the present invention aUows the entire histor^ 
eratively handled by the chent and server applications in the ^ negotiation to be preserved along with its final agree- 
same manner as the mitial request. All communications ^^^^ o o in- 
activities are moderated by the server appUcation and ^'^ Q^her system configurations can be implemented 
recorded in the data repository. i5 using the components of the preferred embodiment with 

The data repository is preferably structured as a set of minimal changes from the above description, 

relational database tables, including a users table and a lo the preferred embodiment, the client application is 

messages table. The users table lists characteristics of all based on a web browser and the server application includes 

system users, including unique ID, name and preferences. communication board software that performs all high level 

The messages table lists characteristics of each message 20 and data repository operations and web server software that 

issued by users, including a unique message ID, threading decodes and encodes communications from and to the client 

information (parent and child message IDs) sender and web browser. Preferably, all communication board contents 

recipientname,subject,stamsof the message (unread, read, displayed to_ users are formatted as ACTIVE SERVER 

responded, acknowledged, etc.), type of message (thread, PAGES whose fields can l^^namicaUy filled in by the user 

invitation, confirmation, log), miscellaneous flags, and the 25 via the client web browse^QTS y tbe_gf--n/ftr*g fy>mt;iynicatio n 

name of the file where the message text is stored on the ^r^ftw are using information from other users a nd/or 

server t he data reTX)sitor v. 

Id the preferred embodiment a sender sends a message to Another feamre provided by the preferred embodiment is 

a recipient by filling in a send message template displayed message hyperlinking, which allows a user to form a 

by the client application, which relays the completed mes- 30 response to any message shown on their private bulletin 

sage infonnation to the server application. Upon receiving board by simply selecting a hypertext link identifying the 

the message information the server apphcation stores the message sender. In response to the selection of a hyperlink 

pertinent information (sender, recipient, subject) in the mes- the client application generates the appropriate response 

sage table, updates message status fields and threading screen with some of the fields (e.g., sender, recipient, 

information for the same message table record, stores the 35 subject) fiUed-in. 

message text in a file, and issues the client application of the The preferred embodiment supports multiple integrated 

intended recipient a pending-message alert. Preferably, the modes, including a threaded communications (message) 

server application sends the pending-message alert only mode, already described, talk mode, conference mode, whis- 

when the users table indicates that the recipient is online, per mode and mail mode. The present invention allows users 

although this is not a requirement of the present invention. 40 to transition smoothly between the modes. 

The client application gives the recipient an opportunity to Conference mode allows users to participate in moderated 

do nothing, cancel the alert, or accept the message. If the or unmodcratcd conferences that arc scheduled or unsched- 

user does nothing, the server resends the alert at some uled. Information regarding conference participants and 

prescribed interval. If the user cancels the alert, the server scheduled time and moderator, if applicable, are stored by 

will not resend the alert and places the message on hold. If 45 the server application in a conferences table within the data 

the user accepts the message, the server sends the relevant repository. When a user is to participate in a scheduled 

message information to the client application to be accessed conference he is notified of the virmal conference room and 

by the recipient. time of the conference by the server application. The server 

When the preferred embodiment is configured as a private application also creates the virmal conference room at the 

message board system, each user interacts with the commu- 50 appropriate time, registers participants, and stores a log of 

nication system via a private buUetin board in which the the conference in the data repository. In a preferred cmbodi- 

client application instantly displays the history and content ment conference mode conversations arc unthreaded, Whis- 

of all messages associated with conversations in which the per mode is available to participants in a conference who 

respective user is a party. In this configuration the present wish to paricipate in a private, side conversation, 

invention supports multiple instances of instant messaging, 55 jaUc mode allows users to participate in informal, 

meaning that it provides private bulletin boards for multiple unlogged conversations. In a preferred embodiment talk 

users and is able to allow each of the multiple users to mode conversations are unthreaded, 

exchange instant messages with one or more other users. In Mail mode allows a user to send e-mail over the Internet 

this case the relevant message information returned by the with two levels of threading, 

server application to the intended recipient includes thread- 60 _ 

ing infomiation. which enables the client application to BRIEF DESCRIPTION OF TOE DRAWINGS 

display the message's history along with that of other Additional objects and feamres of the invention will be 

messages. Preferably, the chent application displays the more readily apparent from the following detailed descrip- 

messages in open format; however, the client apphcation tion and appended claims when taken in conjunction with 

could also display the messages in the conventional format. 65 the drawings, in which: 

Once a recipient has accepted a message, he can reply to FIG. 1 is a block diagram of a preferred embodiment of 

or acknowledge the message. The message reply feature is the present invention; 
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FIG. 2 is a block diagram of the database tables 140, 142, be any program configured to serve web content over a 

144, 146, 148 from FIG. 1; network. The applications 112 also include communications 

FIG. 3A is a data flow diagram illustrating the relation- application 117, which are programs that employ features of 

ships between a client application 166 and web browser 168, server application 114. The data 118 include ACTIVE 
the web server 116, the server application 114 and the PMB 5 SERVER PAGES (ASP) 120 that describe the contents of 

databases 108 when a user is sending a message; web pages through which clients 150 exercise the modes of 

FlG.3Bisablockdiagramofnewrccordsallocatedinthe P'^°* indention, including messaging, conferencing 

various tables by the server application 114 whUe processing Oncorporatii^ ^J"^^' for conference participants), 

an exemplary send request; ^20 therefore includes a messages 

T^r- ■ J* « A- -11 * . 10 page 122, a conference page 124, a whisper page 126, a chat 

f . u ' ^^^^f page 128, a mail page 130 and other pages 132 needed for 

lormed t)y tde web browser ot a message sender, ne miscellaneous client -server communications, 
server application 114 and the web browser 168-2 of a 

message recipient for a message send procedure; , Message mode aUows a user to mteract with a private 

. . . - . . , bulletin board m which his messages (i.e., any message 

FIG. 4B IS an image of a private commumcation board ,s involving the user as sender or recipient) are instanUy 

screen on which mstant messages owned by one user are ^^^^^^^^ ^^^^ ^^^^^^^ information, 

presented m a threaded, open format; ^^^^^^ ^^^^ ^^^^^^^ ^ acknowledge (Ack) reply which, 

FIG. 4C is an image of a second private communication when sent by a user in re^onse to a particular message, 

board screen on which instant messages owned by a second closes the thread comprising the particular message and 
user are presented in a threaded, open format; 20 records the users acknowledgment that they read/accepted 

FIG. 4D is an image of a private message review board the message. Because each bulletin board is private, no user 

that presents for one user all of the user*s messages having other than the authorized user can view its contents, 

a common subject; Conference mode allows users to participate in moderated 

FIG. 5A is a data flow diagram illustrating steps per- or unmoderated conferences that are scheduled or unsched- 

formed by a web browser 168-1 of a message replier, the uled. Information regarding conference participants and 

server application 114, and a web browser 168-2 of a scheduled time and moderator, if applicable, are stored by 

message reply recipient for a message reply procedure; the server application in a conferences table within the data 

FIG.5B is a block diagram of new records allocated in the repository. When a user is to participate in a scheduled 

various tables by the server application 114 while processing conference he is notified of the virtual conference room and 

an exemplary reply request; time of the conference by the server application. The server 

RG. 6 is a data flow diagram iUustrating steps performed appUcation also creates the virtual conference room at the 

by the web browser 168-1 of a message acknowledger and appropriate time, registers partiapants, and stores a log of 

the server appUcation 114 for a message acknowledge the conference m the data repository. In a preferred embodi- 



ment conference mode conversations are unthreaded. Users 

„ L.-n.- L involved in a conference can enter whisper mode, in which 

FIG. 7A is a flow chart illustrating steps by which the ^„ „„*«k«..* 

.-1 r tney can converse privately, without logging. 



procedure; 
FIG. 7A 

server application 114 schedules and implements a confer- 



ence 



Talk mode allows users to participate in informal, 

T^r^ J 1 • L J r unlogged conversations. In a preferred embodiment talk 

FIG. 7B depicts an exemplary commumcations board for ^ ^ . ^ ^ t j « 

^. I ^ -11 . ^- r . n • A An Hiode conversatious are unthreaded. Mail mode allows a 

a particular user illustratmg conference notmcalions and ^ ^ j .u j j -1 *u t * * t7 i. i^^i. 

, ^ user to send threaded e-mail over the Internet. Each of these 

announcements: , . . , . . . - 

„^ ^ , ^ modes is mtegrated so that users can transition from one to 

FIG. 7C depicts a conference screen displayed by client jjjg other 

Web browsers 168 for all clients participating in a confer- , r j ^ . l , . • 

r r o In the preferred embodiment, the database 108 is a 

. , . „ 45 relational database system including tables organized to 

RG. 8A IS depicts a talk emry screen displayed by chent ^^^^^ information written and retrieved by the server appli- 

Web browsers enabhng a user to transition to taUc mode; ^^^-^^ operation. The database tables 

FIG. 8B is depicts a taUc session screen displayed by cUent include a users table 140, messages table 142, conference 

Web browsers during a talk session; and table 144, threads table 146 and a thread participants table 

FIG. 9 depicts a mail screen displayed by client Web 50 148. The tables 140-148 respectively store information on: 

browsers that supports threaded Internet e-mail. system users (140), messages exchanged between users 

(142), conferences of users (144), mapping of messages to 
threads (146), and mapping of thread participants (users) to 
threads (148). These tables are described in depth in refer- 

Referring to FIG. 1, there is shown a block diagram of a 55 ence to FIG. 2. The hard disk 104 includes message files 

preferred embodiment of the present invention. This 136, which store the text of messages referred to by the 

embodiment includes a server 100 with a server memory messages table. 

106, processor 102, hard disk 136 and database 108. The The embodiment shown in FIG. 1 also includes one or 

server memory 106 could be any combination of a RAM or more clients 150, each of which is used by one or more 

cache memory and includes an operating system HO, appli- eo users. The single chent 150 shown is representative of the 

cation programs 112 and data 118. In accordance with well one or more possible clients. In the preferred embodiment, 

known principles, the processor 102 executes the applica- clients 150 are coupled to the server 102 via an intranet 160; 

tions 112 in the memory 106 under control of the operating however, the principles of the present invention are equally 

system 110. appficable to any type of network, such as the Internet, an 

The applications 112 include a personal message board 65 extranet or combinations thereof. The client 150 and the 

(PMB) server application embodying many of the teachings server 100 exchange information over the network 160 using 

of the present invention and a web server 116, which could standard network protocols, such as TCP/IP and HTTP. In 
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particular, the server application 114 makes available to 
users communication board services (encompassing private 
message boards, chat, talk, conferencing and mail) by trans- 
mitting to the clients 150 via the web server software 116 
manifestations of the ACTIVE SERVER PAGES 120 and 
other web pages. These manifestations, when displayed by 
the clients 150, enable the users to view communications 
board information and messages from other users, and to 
issue requests and queries to the PMB application 114 via 
the web server software 116. 

The client 150 includes a memory 156, processor 152, 
hard disk 154 and user interface elements 158, such as a 
display, keyboard and selection device. The memory 156 
could be any combination of a RAM or cache memory and 
includes an operating system 162, application programs 164 15 
and data 170. In accordance with well known principles, the 
processor 152 executes the applications 164 in the memory 
156 under control of the operating system 162. 

The applications 164 include a personal message board 
(PMB) client application 166 and a web browser 168. The 
web browser 168 receives, transmits and presents manifes- 
tations from the ASP 120 and other pages transmitted over 
the web by the server application 114 via the web server 116. 
//The client application 166 provides additional processing 
wl^ capabilities not present in the web browser 168 to assist 
\ users in interacting with the communication board features. 
These additional processing capabilities can include: 
responding to alerts from the PMB application 114 when the 
user is not available, locally logging user sessions, main- 
j taining a local address book for the user and issuing standard 
queries or requests to the server application 114. Note that 
simple implementations of the present invention can elimi- 
nate the PWB server application 166; in such an implemen- 
tation all user interaction would be provided by the web 
browser 168. Because ^com m unicatio ns between the server 
100 and clients 150 adhere to web standards and the key 
components of the present invention (i.e., the PMB server 
application 114 and PMB client applications 166, described 
below) are compatible with standard web software (i.e., the 
web server 116 and browser 168), the present invention can 
be implemented in any web based client server environment. 
Moreover, with slight modification, the server and client 
applications 114, 166 could be made compatible with any 
standard client/server communications packages (e.g., 
Novell, etc.). 

The data include manifestations 172 of the ACTIVE 
SERVER PAGES (ASP) 120 downloaded by the web 
browser 168 in response to events or user requests. These 
manifestations (not shown in detail) enable thfe user to 
employ and interact with the features of the ^MB server 
application, including the following modes: messaging, bul- 
letin board, conferencing, chat, and mail. The manifestations 
are presented by the web browser 166 to users as visuals 162 
and/or sounds 164 using the user interface elements 158. 

The present invention is not limited to the described 
embodiment. In fact, the teachings of the present invention 
are applicable to any combination of current and/or future 
technology similar to that described herein. For just one 
example, the database 108 can be implemented using an 
object-oriented DBMS, flat text files stored on a hard disk 
104, or other DBMS or non-DBMS solutions. Having gen- 
erally described the preferred embodiment, the tables man- 
aged by the database system 108 are now described in 
reference to FIG. 2. 

Referring to FIG. 2, there is shown a block diagram of the 
database tables 140, 142, 144, 146, 148 from FIG. 1. The 
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users table 140 holds information pertaining to authorized 
users of the communication board (i.e., the server applica- 
tion 114). The users table 140 fields include: 



Id Unique number automatically assigned to each user, 

[primary key] 

Name Assigned name for user's account, tlsed to logon with. 

DisplayName User's name as it appears in the heading of their Co mm 
Board. 

Password To restrict account access by unauthorized users. 

SortPrcfs User's sorting preferences - a 3 character code; 

c=chranological, r^reverse chronological, s=subject, 

ExpiryE*rcf Number of days after which a message cjcpircs and is 
deleted. 

HasNewMail Flag is set to true when user has unread mail. 
Haslnvitation Flag is set to true when user has been invited to join a 
conference. 

HoldAlerts Flag is true if user does not want alerts for new 
messages, etc to interrupt their session. 



The messages table 142 holds information pertaining to 
individual messages. Each participant in a message owns an 
individual message record. This allows for personalized 
manipulation of a given message. The messages table 142 
fields include: 



Msgid 

MsgFilcName 
ThreadLevel 
Threadld 
Parcntid 



Childld 

MsgTimeStamp 

MsgRecOwner 

Senderld 

ScndcrName 

SenderNameASCI 

Recipient 

RccipientList 

Cclist 

IsCarbonCopy 

Subject 

SubjectASCI 

AckDate 

IsRespoodedTo 
Status 
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ExpiryDatc 

IsForward 
ForwardThieadld 



Unique number assigned automatically to each 

message, [primary key] 

Name of fiJc that contains message body text. 

Number 1-6 designating message's level in thread. 

Id of corresponding Threads table record. 

Id of message that is above this message in the 

message thread. Value is zero if message is at top of 

thread. 

Id of message that is betow this message in the 
message thread. Value is zero if message is at the 
bottom of thread- 
Year, month, day, hour, minute and second when 
message was sent. 

Name of user that owns this message record (sender 
or recipient). 

User Id of message sender. Corresponds to id in 
Users table. 

User name of message sender. 

SenderName sort number. 

User name of message recipient. 

Complete comma delimited list of recipients. 

Complete comma delimited list of carbon copy 

recipients. 

Flag is true if recipient is in ccList rather than 
redpientlisL 

Message subject or conference name. 
Subject sort nirniber. 

Date message was acknowledged rather than 
responded to. 

Rag is true if message has been responded to. 
Message status contains one of these values: unread, 
read, repliedTo, acked, stored, deleted, abandoned. 
Type of message contains one of these values; 
thread, announcement, invitation, confirmation or 
log. A thread type is a message that appears as part 
of a thread. An announcement is a simple message 
sent to all users by default. Announcements do not 
allow for a reply. An invitation is automatically sent 
to users that are invited to a conference. A 
confirmation is automatically generated when a 
user re^>onds to an invitation. A Ic^ is a complete 
record of a given conference. 
Date message is to be expired (automatically 
deleted). 

Flag is true if message ts forwarded. 
Id of thread being forwarded. 
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A thread includes a first level message and subsequent 
replies, which can be added to the thread until the thread is 
closed by one of the thread participants issuing an explicit 
acknowledgment to one of the thread *s messages. The 
threads table contains one thread record for each message 5 
thread that is unique by subject. The threads table 146 fields 
include: 



10 



Threadid Unique number assigned automatically to each thread. 

[primary key] 
Subject Thread subject. 

SubjectASCI Sort number for subject. 



Whenever a user participates in a thread — that is, when he 
is a sender or recipient (even if only a CC recipient) — an 
entry is made by the server application 114 in the thread 
participants table 148. This table facilitates the gathering of 
message threads by subject for a given user. For example, 
the server application 114 would gather such information for 
a particular user by: 

1) issuing a query in the ThreadParticipants table 148 to 
find Threadlds of all threads a user with a particular 
UserlD has participated in; ^5 

2) issuing a query in the Threads table 146 using the 
ThreadlDs from query 1 to identify the subject sort 
numbers (SubjectASCI) for the respective threads; and 

3) issuing a query in the Messages table 142 with the 
SubjectASCI values from query 2) to identify all mes- 30 
sages with the same subject for the user. 

The thread participants table 148 fields include: 



Participantld Unique number assigned automatically to each thread, 
[primary key] 

Threadid Thread ID (correlated with ttu^ad subject). 

User Id ID of user who is thread participant. 



The conferences table 146 holds basic information about ^ 
each conference. The conferences table 144 fields include: 



45 



Id Unique number assigned automatically to each 

conference, [primary key] 
Modcratorld User id of conference moderator. 
Topic Moderator assigned topic for conference. 

Type IVpc of conference contains one of these values: private, 

public. 

Participants Comma delimited list of users invited to join a private 
conference. 

IsScheduted Flag is true if the conference is scheduled for a later date 

as opposed [to?] immediately. 
When Tunc of conference if the conference is scheduled for a 

later time. 



55 



Referring to RG. 3 A, there is shown a data flow diagram 
illustrating the relationships between a client appUcation 166 
and web browser 168, the web server 116, the server 
application 114 and theJB MB databases 108 when a user is 
sending a message. The progression of operations shown in 60 
FIG. 3 is preceded by a SEND request issued by a user that 
is relayed via the user's web browser 168 to the sender 
application 114 via the web server 116. The sender appli- 
cation 114 in response returns a manifestation of a SEND 
page, which the web browser 168 displays as a SEND page 65 
visual 162. The user then completes at least a subset of the 
fields of the SEND page, which include: TO (i.e., one or 



more recipients), FROM (i.e., sender name), SUBJECT (i.e., 
message subject) and MSG (i.e., message text). It is assumed 
for this example that the message being sent is a level one 
message that starts a new thread of conversation. 

The progression shown in FIG. 3 A. begins when the user 
sends the message by selecting the displayed SEND button 
on the visual (3.1). In response to the selection of the SEND 
button (3.1) the web browser 168 (possibly with some 
intervention of the client application 166) issues an HTTP 
message transferring the SEND data to the web server 116. 
In accordance with the HTTP (hypertext transfer protocol) 
the browser 168 transmits the SEND data to the web server 
116 (3.2). The message (3.2) includes the URL of the page 
for which the data is being transmitted (i.e., "SendMsg") and 
the encoded data. Upon receiving the message (3.2) the web 
server 116 decodes, re-packages, and transmits (33) the data 
to the server application 114. 

Upon receiving the message (3.3), the server application 
114 performs the following operations (3.4-3.14): 

3.4) Determines from the users table 140 the IDs of sender 
and recipient(s). 

3.5) Writes the MsgTxt to the hard disk (3 .5) as a message 
file 136 and generates a corresponding file name 
(MsgFileName). 

3.6) Generates a unique ID (MsgID) and sortable subject 
number (SubjectASCI) for the message. 

3.7) Allocates in the messages table 142 2 N message 
records 143, N for the sender 143s and 1 for each of the 
N recipients 143ri (where i is an integer between 1 and 

N); 

3.8) Updates each message record in accordance with the 
message data (only selected field are shown): 
MsgID=*message ID generated by server app. 114; 
MsgFileName -message name generated by server app. 

114; 

ThreadLevel=l (message is at the top of a thread); 

ParentID=0 (message is at the top of a thread); 

CliildId=0 (message is also at the bottom of a thread); 

MsgRecOwne rename of a reject ive one of the par- 
ticipants SenderID=ID of sender; 

ScnderName=user name of sender; 

Recipient=user name of a respective one of the N 
recipients; 

RecpientList-list of N recipients; 

Subject-subject completed by sender; 

SubjectASCI=subject sort number generated by server 
app. 

AckDate=0 (message not yet responded to); 
Status=unread (message not yet received); 
Type=thread (message is part of a thread); 

3.9) Generates a unique thread ID (ThreadID) for the 
thread started by the message. 

3.10) Allocates a single record 147 in the threads table 
146; 

3.11) Updates the thread table record: 
ThreadID=thread ID generated by server app. 114; 
Subject=subject completed by sender; 
SubjectASCI=sort number for subject generated in 

step; 

3.12) Generates a participant ID (ParticipantlD) for each 
participant (1 for sender and 1 for each of the N 
recipients); 

3.13) Allocates in the ThreadParticipants Table 148 N+1 
records 149, one for the sender 149s and N for each of 
the N recipients 149ri (where i is an integer between 1 
and N); 
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3.14) Updates each ThreadParticipanl record 149 as fol- 
lows: 

Participant! D=participant ID generated by server app. 
114 

ThreadID=thread ID generated by server app. 114 
UscrID=messagc name generated by server app. 114 
ThrcadLevel=l (message is at the top of a thread); 
Referring to FIG. 3B, there is shown an example of how, 
as a result of the send processing performed by the server 
application 114, multiple records of the respective tables are 
generated and cross-referenced. FIG. 3B assumes a simple 
example where a user with useraame AmieS has sent a 
message to two co-workers, BobB and SueG. Information 
for these users is provided in the users table 140, which 
shows UserlDs (U007, U019, U027) and DisplayNames 
(Amie, Robert, SueEllen) for AmieS, BobB and SucG, 
respectively. Upon receiving the message the server appli- 
cation 114 creates four new message records M001-M004 in 
the messages table 142. Two messages (Msgld-MOOl, 
Msgld-«M002) list AmieS as MsgRecOwner; one of these 
has BobB as Recipient and the other has SueG as Recipient. 
The other two messages (MsgId=M003, MsgId=M004) are 
similar, but hst BobB and SueG as respective MsgRecOwn- 
ers. Multiple messages are created so each participant 
(sender or recipient) can independently manipulate their 
own messages. For the same message, a single new Threads 
table 146 record has been allocated (Threadld-TOOl). This 
single record is associated with all messages having the 
same subject (i.e., "The Lee Account") and a corresponding 
unique index (S050). This same ThreadID is associated, for 
example, with any reply by any of the recipients of the 
original message as well as any subsequent replies by the 
original sender. The server application also allocates 3 
thread participant records (with ParticipantIds=P021, 025, 
032), one each for AmieS, BobS and SueG. These partici- 
pant records map the participants to their respective uscrlDs 
(U007, U019, U027) and to the new thread record 
(Threadid=T001) associated with the subject common to all 
messages. 

Referring to FIG. 4A, there is shown a data flow diagram 
illustrating steps performed by the web browser 168-1 of a 
message sender, the server application 114 and the web 
browser 168-2 of a message recipient for a message SEND 
procedure. The steps illustrated in FIG. 4A occur after the 
user of ±e client 150-1 has sent a message (4.1) designating 
a user of the client 150-2 as recipient and the server 
application 114 has processed that message as described in 
reference to FIG. 3 A. As part of the processing described in 
reference to FIG. 3A the server application 114 determines 
the recipient(s) of the message (4.2). The server 114 then 
determines whether the recipient(s) is/are on the system 
(4.3). If the recipient is on the system, the server application 
114 sends a message alert (MsgAlert) to the recipient (4.4). 
The MsgAlert (4.4) notifies the intended recipient that a first 
level message is waiting for him. The recipient application/ 
browser 166-2/168-2 displays the alert in an alert window 
(4.5) that gives the recipient two response alternatives: OK 
or CANCEL (4.6). The recipient selects OK to indicate to 
the server application 114 that he wishes to receive the 
message. He selects CANCEL to indicate that he does not 
wish to receive the message and does not want to receive 
further alerts. The recipient can also choose not to respond 
to the alert at all. This commonly occurs when the recipient 
is away from his computer. 

After sending the MsgAlert (4.1) the server application 
114 waits (4.7) for the recipient's response. If the response 
is NULL, (meaning that the recipient did not re^nd for 
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some predetermined time interval; e.g., 90 seconds) the 
server application 114 resends the MsgAlert (4.8fl). 

If the response is OK, the server application sends the 
Message (4.8^) and updates the messages table 142 to show 

5 that the message has been posted. This update involves 
changing the status 260 of the messages table records 230 
for the sender and recipient of the message from "unread" to 
"read" 230. The server appUcation 114 also sends at the 
same time any other messages which were in abeyance at the 
server 100 (i.e., messages previously sent but not OKed for 
delivery by the recipient). The status of each of these 
messages is also updated accordingly by the server apph- 
cation 114. The recipient application/browser 166-2, 168-2 
then displays the messages in an open, threaded communi- 
cation board format that is a key feature of the present 

15 invention. This display format is described below in refer- 
ence to FIG. 4B. A unique a^ect of the described sequence 
of operations is that a user is able to view their communi- 
cation board messages instantly (that is, as soon as they issue 
an OK), without first needing to log on to a centralized 

20 bulletin board system. Another advantage of the present 
invention is that the messages are displayed with full 
threading, which is not possible with conventional instant 
messaging systems. 

If the re^onse is CANCEL, the server application 114 

25 places the message in abeyance (i.e., does not send it) and 
sends another message to the application/browser 166-2, 
168-2 causing a message indication to be displayed/played 
on the client user interface 158. For example, the message 
indication could be an alert light or a sound indication, 

30 among many other possibilities. 

Referring to FIG. 4B, there is shown an image of a 
communication board format 400 employed by the present 
invention to display for a single user the contents and status 
of conversational threads (e.g., 460, 462, 464, 466) in which 

35 that single user has participated. This image is displayed as 
a visual 162 on the user^s client computer by the application/ 
browser 166-2/168-2 based on inputs received firom the 
server application 114. The communication board 400 dis- 
plays all messages and threads owned by a user regardless 

40 of subject. These messages are displayed until they are 
deleted by a participant, they expire, some event occurs that 
triggers their automatic deletion, or the system administrator 
deletes them. In addition to messages (including forwarded 
and carbon copy (cc) messages), the communication board 

45 400 displays announcements broadcast to multiple users and 
conference notifications. 

The communication board 400 lists for each message 
information firom a corresponding messages record, includ- 
ing its MsgTuneStamp 242, Recipient 246, SenderName 

50 245, Cclist 250, Subject 254 and MsgText. In the illustrated 
embodiment the MsgTimeStamp 242, Recipient 246, 
SenderName 245 and CcList 250 are displayed on the first 
line 402 of a message, which is called the information line. 
The Subject 254 is displayed on the second line 404 and the 

55 MsgText 406 is displayed on subsequent lines. 

In a preferred embodiment, the communication board 
display is private, meaning that each user can view only their 
messages (i.e., messages for which a user is listed as 
MsgOwner in the messages table 142). The present inven- 

60 tion is able to support this private treatment of messages as 
it allocates for each one-to-one communication two message 
records 230, one owned by the Sender and one by the 
Recipient. A unique feature of the present invention is that 
messages and replies thereto appear simultaneoxisly on the 

65 communication boards of both the sender and the recipient. 
The client displays the messages with full threading 
information. That is, first level messages 442 are displayed 
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with no indentation and lower level messages (i.e., replies 420 is left blank on the sender's communication board 400 

444 and replies to replies 446) are displayed with cxtrre- (e.g., see the Ack field 420-3). Therefore, at all times a 

spending levels of indentation. The information necessary to sender is able to determine the current status of their 

maintain message threading is provided by the server appb- outgoing messages without needing to login to another 

cation 114 from the Parent, Child, ThreadLevel and 5 service — i.e., the status is displayed through the visual cues 

Threadid fields 238, 240, 236, 237 of the messages table presented on the communication board screen 400. 

142. In particular, each displayed thread comprises a first In the preferred embodiment, information lines 402 for 

level message and its children (family of replies). Note that incoming messages have a hyperlink function such that 

many threads can have the same subject (e.g., the threads selecting the underlined portion of the information line 

460 and 464); however, each first level message with the causes the application server 114 to return a reply screen/ 

same subject is displayed as a distinct thread. visual 162 that is partially filled out with the appropriate 

To assist user recognition of the different message levels Recipient, Sender and Subject. The message reply proce- 

and the status of those messages (read, unread, etc.), the jures implemented in the present invention are described 

displayed embodiment employs color and icons in addition ^elow, in reference to FIG. 5. There is no hyperlink function 

to mdentation In particular, fir^t level messages are pre- associated with the information lines of the outgoing mcs- 

ceded by a filled-m square 408, second level messages saees 

(replies) are preceded by a fiUed-in diamond 410 and third ^ „f ^j^^ 4B ^^^^ 

level messages (repbes to rephes) are preceded by a fiUed-in . - i_ ^^rwnr ^ 

■ 1 T *u 11 * * J u J - * X • r 1- r shows the communication board 400 for the user, Mit . The 

circle. In the illustrated embodiment the information hne of • l j . , ' 

incoming messages is underlined with difeerent colors communication board 400 shows Mit has 9 current messages 

depending on whether the message has been responded to 20 and 4 open messages, which are messages that have not been 

(shown in purple) or need to be responded to (shown in closed/ac^owledged). The underhned message headers are 

blue). Alternatively, the information line of all incoming associated with repbes to Mil and the plamly-displayed 

messages can be shown in one color (e.g., blue) and with ^^^^^ headers are associated with messages sent by Mit. 

underlining only when the incoming message has not yet ^^f^f^ ^^^^ ^^^^^^ 

been responded to. Note that these display features 25 thread 460 comprises two messages of the following levels: 

(indentation, color, icons) are not required by the present ^^^^1 ^ ™sg 442, to Arlene from Mit; and 

invention but are niceties to assist users in navigating the level 2 reply 444 to the level 1 msg; 

open, threaded communication board 400. Each message is displayed in open format, meaning that 

A novel feature of the present invention is message text can be read without selecting/opening the message, 

acknowledge (Ack), which allows a message recipient to 30 For example the first level message 442 has the follov^dng 

agree to/acknowledge a particular message in such a way openly displayed MsgText: 

that their agreement/acknowledgment is unambiguously "Pis order 3R report on 145 Piccadilly and give copy to 

recorded by the server application 114. In the displayed Agnes." 

embodiment the present invention displays an Ack field 420 The message 442 was responded to by Arlene, whose 

alongside the information bne 402 of all second and third 35 reply 444 includes the following MsgText: 

level messages that indicates when and how (explicity or "3R report ordered. Will give copy to Agnes." 

implicitly) a message was acknowledged. An Ack field 420 In response to Arlene's 444, which clearly closed out the 

is not displayed next to first level messages in the preferred conversation, Mit sent an expUcit acknowledgement that 

embodiment, but this could also be done in alternative caused the server appUcation 114 to close the thread 460. 

embodiments. The acknowledge feature is useful in business 40 Thus, the Ack field 420-1 of the message 444 is shown 

applications where it can be used to memorialize agreement; underlined, indicating thread closure, 

e.g., to proposals contained in messages. The acknowledge Due to the symmetry with which the message records are 

feature also serves to inform senders as to whether or not created (i.e, two message records created per communica- 

recipients have read their messages. tion pair), similar message information is displayed in real 

When a user acknowledges a message (explicitly or 45 time on the communication boards of all participants to a 

implicitly) the server application 114 displays the date and thread. For example, referring to FIG. 4C, there is shown a 

time of the acknowledgment on both the sender and the portion of Arlene's communication board 400 A bsting some 

recipient's communication boards 400. Explicit selection of the same threads 460, 462 as Mil's board 400. In 

results in the closing of a thread, meaning that no more particular, Arlene's thread 460A and messages 442A, 444A 

repbes on that particular thread are possible and that sub- 50 correspond to Mil's thread 460 and messages 442, 444. Note 

sequent conversations on the same subject would require a that, on both boards 400 and 400 A, the Ack information 

new first level message. In the displayed embodiment the 420-1 for tbe corresponding messages 444 and 444A is 

Ack field of closed threads are underlined with a character- identical. However, the information bnes of the messages 

istic color (e.g., red) on the communication boards of both 444 and 444A differ. That is, on Mit's board, the information 

participants (e.g., see the Ack field 420-1). 55 fine of the message 444 (from Arlene to Mit) is underlined 

A user can impbcitly acknowledge a received message by but, on Arlene's board, the corresponding information bne is 

replying to that message (e.g, by sending a third level not underlined. This because Arlene was the sender of this 

message). In this case the server application 114 fiUs in the message. Other differences between Arlene's and Mit's 

Ack line 420 of the second level message with the date and boards are due to the fact that Arlene and Mit participate in 

time the third level message was sent. When such a reply is 60 different threads with different users, 

sent the server appUcation 114 does not close the thread as A user can choose an alternative view of their messages 

the reply merits its own acknowledgement. As a result, the by using the message review board feature of the present 

server application 114 does not display the Ack field 420 invention. A message review board presents a view of all 

with the characteristic color of a closed thread (e.g., see the messages in the user's message folder (i.e., stored messages) 

Ack field 420-2). 65 with a common subject. For example, referring to FIG. 4D, 

If the recipient of a second or third message has not which shows a message review board 1400, the threaded, 

repbed or acknowledged to such a message, the Ack field instant messages shown are all associated with the same 
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subject 1404 ("145 Piccadill/*) and are owned by the user, reply procedure. The steps illustrated in FIG. 4A occur after 

"Mil". The message review board presents the messages io the user of the client 150-2 has received a message (4.1) 

the same manner as a communication board. The underlined from a user of the client 150-1. Upon displaying a message 

message headers are associated with replies to Mil and the on their communication board as described in reference to 

plainly-displayed message headers are associated with mes- 5 FIG. 4, a user can choose to reply to that message by 

sages sent by Mit. The example of FIG. 4D includes three selecting a reply option from a menu, an icon, or other 

threads 1440, 1460, 1480. The thread 1440 comprises three equivalent methods (5.1). Once the user has selected the 

messages of the following levels: reply option a reply box is displayed (52) that allows the 

level 1 msg 1442, to Arlene from Mit user to specify the reply's recipient and subject (these fields 

level 2 reply 1444 to the level 1 msg; and ^° ^^^^ ^° ^^^^^^^ sender's information) and 

a level 3 reply 1446 to the level 2 reply; ^^S'^"^^* V"^ reply box description could be sent by the 

Each message is displayed in open format, meaning that ''''^^ f wA^^ ^^u""' 

, t u ^ -.u * 1 *• / • *u apphcation 166-1. The user fills m the reply (5.3), and then 

its text can be read without selectmg/openmg the message. . «- , . .^n • 

For example the firet level message 1442 has the following ^""^ " f '"J^" application (5.4). Key inforniation 

openly displayed MsgText: conveyed to the senrer m the reply mcludes the Msgld of the 

,^^„ . . 1 . P . , message responded to. 

mere are the si^ed copies of the TDS and Supp TDS? ^ ^^^^ appUcation U4 assigns a unique 

I need to provided copies to the lender. ^^^j^ ^ j (5 ^^^^^^^ corresponding message 

The message 1442 was responded to by Arlene, whose ^^^^^^ 230 for the reply sender and recipient (5,6) and 

fiTf^f •''''tT ^ updates database 108 records accordingly, including setting 

1400. Arlene s reply 1444 mcludes the foUowing MsgText: p^^,„j ^^ild pointers to and from other message recorcfe 

"Buyer's agents will be droppmg off signed copies tmo. 230 (5.7). The server application 114 then posts its reply to 

I will go ahead and give copies of same to the Lender the indicated recipients (e.g., the user of the client 150-1) IF 

when I get them back." they are onUne (5.8). Note that, unlike first level messages, 

Mit repUed to the reply 1444 with another reply 1446: 25 the server appKcation 114 does not issue queries to recipi- 

"Thanks a whole lot. That will save me a lot of time. I owe cnts asking if they would like to a reply to be sent. Instead, 

you one!" the server application 114 pushes replies to recipients. 

By sending this reply 1446 Mit implicitly acknowledged Morever, every time it pushes one reply, the server appli- 

the reply 1444 from Arlene. Consequently, the thread 1440 cation 114 pushes all other replies held in abeyance (except 

is still open and the server application 114 sets the date and 30 for first level messages not yet accepted). An illustration of 

time of the acknowledgment 1420-1 to the date and time the databases 108 reflecting processing by the server appli- 

(10-04-97 16:14) Mit sent the reply 1446. cation 114 in response to a reply is now described in 

In response to the reply 1446, which clearly closed out the reference to FIG. 5B. 

conversation, Arlene sent an explicit acknowledgement that Referring to FIG. 5B, there is shown an example of how, 

caused the server application 114 to close out the thread. 35 as a resuU of the reply processing performed by the server 

Thus, the Ack field 1420-2 of the message 1446 is shown application 114, multiple records of the respective tables are 

underlined, indicating thread closure, generated and cross-referenced, FIG. 5B assumes a simple 

The preceding description is directed to an embodiment of example where SueG has responded to the message sent by 

the present invention where the commimication boards are AmieS (refer to discussion of FIG. 3B). Upon receiving the 

private and provide instant, open display of threaded mes- 40 reply message the server application 114 creates two new 

sages. Alternative and equally novel embodiments of com- message records MOOS, M006 in the messages table 142. 

munication systems can employ various combinations of one One of these messages (Msgld=M005) lists AraieS as 

these concepts (privacy, instant messaging, threading and MsgRecOwner and Recipient and SueG as Sender. The other 

open display). For example, the teachings of the present message (Msgld=.M006) is similar, but Usts SueG as MsgRe- 

invention could be employed in the following novel sys- 45 cOwner and sender and ArnieS as Recipient. Anew Threads 

tems: table 146 entry has not been allocated as the subject (i.e., 

1) public bulletin boards with open display of messages; "The Lec Account") and subject index (S050) for the reply 

2) e-mail systems with open display of messages; ^^e already represented by the Thread TOOL Nor are new 

3) e-mail systems with threading of messages; ThreadParticpant table 148 entries allocated. This is because 

4) private buUetin boards with no other unique feaUires; two participants in the reply (AimeS and SueG) have 

. ^ . ' appropnate records (with Participantlds-P021 and 032) in 

5) private buUetm boards with instant messagmg; ThreadParticipants table 148, 

6) private bulleting boards with instant messaging and Referring to FIG. 6, there is shown a data flow diagram 
open display; and illustrating steps performed by the web browser 168-1 of a 

7) instant messaging systems with threaded of messages. 55 message acknowledger and the server application 114 for a 
Descriptions of these embodiments are not provided message acknowledge procedure. The steps illustrated in 

herein as their respective implementations should be appar- FIG. 4A occur after the user of the client 1^-2 has received 

cnt from the descriptions already provided. Other embodi- a reply message (5.7) from a user of the client 150-1. A user 

ments consistent with these teachings and descriptions will can choose to acknowledge expHcity a message displayed on 

occur to the reader skilled in the art and are within the scope 60 their communications board 400 by selecting an Ack option 

of the present invention. Having described the communica- from a menu, icon, or other equivalent means (6.1). In 

tion board concept, the message reply process is now response, the client apphcation/browser 166-2/166-3 relays 

described. pertinent information (including Msgld) for the message 

Referring to FIG. 5 A, there is shown a data flow diagram being explicitly acknowledged to the server application 114 

illustrating steps performed by a web browser 168-1 of a 65 (6:2). The server application 114 processes the message 

message replier, the server application 114, and a web acknowledgment as described in reference to FIGS. 4A-4C 

browser 168-2 of a message reply recipient for a message and updates the databases 108 accordingly (6.3), principaUy 
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by changing the status of the relevant message record to 
"ACKed" and completing the AckDate 256 (FIG. 2). The 
server application 114 then posts the acknowledgement to 
the respective communications boards 400 of both partici- 
pants (i.e., the sender using the client 150-1 and the recipient 5 
using the client 150-2) as described in reference to FIGS. 
4B-4C (6.4). In a preferred embodiment the acknowledg- 
ment is only sent when the sender is ooUne. 

Alternatively, as described above, an acknowledgment 
can be sent implicitly as the result of a recipient of other than 
a first level message responding to that message. In this 
situation the server application 114 allocates new message 
records 230 in the same manner as for a reply (FIG, SB); i.e., 
the Status 260 of those records is not listed as Acked and the 
AckDate 256 (FIG. 2) is not filled in. Additionally, the 
IsRespondedTo flag of the parent messages is set. 

An example of the databases 108 resulting from the 
processing of an acknowledgment is not shown given the 
similarity of these results to those in the reply case, already 
described in reference to FIG. 5B. 

In addition to the communication board features described 20 
above, the present invention provides additional conference, 
whisper, talk and mail modes. It is a key feature of the 
present invention that these modes are integrated with the 
commimications board features. It is now described refer- 
ence to FIG. 7 how the server application 114 supports ^5 
conference mode. 

Referring to FIG. 7A, there is shown a flow chart illus- 
trating steps by which the server application 114 schedules 
a conference, notifies conference participants and holds the 
conference. As the first step in scheduling a conference a ^0 
user/moderator begins conference mode operations (702). 
The moderator then schedules a conference (704) by defin- 
ing its: 

participants (one or more users if conference is private, 

not necessary when conference is open); 
topic; 

data and time; and 

type (open or private), where open means that any user 
can participate in the conference and private means that ^ 
a user can only participate if invited by the moderator. 

This information is entered by the moderator on a con- 
ferences page 162 generated by a browser 168 from infor- 
mation (typically formatted as ACTIVE SERVER PAGES) 
forwarded by the server application 114. The completed 
conference page 162 is returned to the server application 
114, which aUocates a new record 270 in the conferences 
table 144 (706). The server application 114 updates the fields 
(706) of the new conference record 270 as follows: 

50 



ID set to a unique ID generated by the applicatioo 114; 

Moderator set to the user name of the moderator. 
Topic set the topic defined by the user on the conferences 

page 162; 

Type set to type (open or private) selected by the moderator. 

Participants set to participants entered by the moderator; 
IsScheduled set to 1 if the user indicated chat the conference is to be 

scheduled for future as opposed immediately; and 
When date and time entered by moderator. 

60 

Finally, the server application 114 schedules a virtual con- 
ference room for the future, or immediately, depending on 
when the conference is scheduled (706). 

Depending on when the conference is scheduled, at an 
appropriate time (which could be immediately or sometime 65 
in the future) (708- Y) the server appHcation 114 sends 
notifications to the conference participants (710). 



As shown in FIG. 7B, which is an image of user Mit's 
communication board 720 including conference notifica- 
tions and announcements, the notifications are displayed 
similarly to messages (including the possibility of 
acknowledgements). In particular, open conference 
notifications, such as the notifications 722, 728, are sent to 
all users, and private conference notifications, such as the 
notifications 746, 752, and 756, are only sent to invited 
participants. Referring to an exemplary notification 722, all 
notifications display: 

a subject 740 that indicates the type of notification (e.g., 
PRIVATE CONFERENCE NOTIFlCAnON); 

the virtual conference room 742 (e.g.. Room 1258); 

the date and time 744 of the conference (e.g., NOW); 

the topic 746 (e.g., "A£fect of new Health Ins Benefits"); 
and 

an IN PROGRESS indication 748 if the conference is in 
progress. 

Note that private conference notifications can be acknowl- 
edged in the same manner as messages. For example, in 
response to the notification 732 from Arlene regarding a 
private conference to discuss future Christmas parties, Mit 
issued a confirming reply 734, which was later acknowl- 
edged 750 by Arlene. The acknowledgment 750 also closes 
the thread consisting of the messages 732, 734. 

EIG. 7B shows another featiure of the present invention, 
announcements 724, 730, which are immediate messages 
broadcast to all users who are online. 

Referring again to FIG. 7A, at the scheduled time the 
server application 114 hosts the conference (714) by: 

allocating the virtual conference room; 

notifying all participants again that the conference is 
starting (e.g., the IN PROGRESS notification 722); 

and allowing the moderator to administer the conference 
in accordance with the type of conference (e.g., if the 
conference is public, users can join at will, but if the 
conference is private, users can only join at if invited by 
the moderator). 

One example of a conference session screen 770 is shown 
in FIG. 70. The screen 770 includes an agenda 772 defined 
by the moderator, a comment screen 774 on which com- 
ments typed by participants on their own conference input 
screens are displayed and a list of participants 776. litis 
screen 770 is displayed for all users who are participants in 
the conference by their respective browsers 168. In a pre- 
ferred embodiment all conference information is logged by 
the application server 114 on the hard disk 104. The screen 
770 includes an ANON button, which, when selected, allows 
a user to participate in the conference anonymously. 

A unique feature of the present invention is whisper mode, 
which is implemented in conjunction with conference mode. 
During a conference two users who wish to carry on a 
private, unlogged conversation can enter whisper mode. 
When in whisper mode users view their conversation on a 
whisper mode screen on which only their comments are 
displayed. No other user can view comments made by 
whisper mode participants. 

Referring to FIG. 8, there is shown an exemplary talk 
session dialog input screen 800 in which a user (e.g., Arlene) 
enters a talk message 804 she would like to send to another 
user 802 (e.g, Mit) as part of a talk session. In the preferred 
embodiment, a user can start a talk session from any system 
mode other than conference mode. When the user is satisfied 
with the message 804, they selea the send button 806, which 
causes the client application/browser 166, 168 to send the 
information from the talk session dialog input screen to the 
server application 114. 
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The server application 114 then determines whether the 
intended talk session participant (e.g., Mit is online). If the 
intended participant is online, the server application 114 
sends him a talk mode incoming message box, which 
announces a new incoming message and gives the intended 
participant the option of checking the message (i.e., joining 
in the talk session) or decHning to participate. The incoming 
message box is displayed for the intended recipient no 
matter which mode his client 150 is in. If the intended 
participant declines to talk or is not available, the server 
application 114 sends the requester (e.g., Arlene) a party not 
available message, indicating that the talk session cannot 
commence. If the intended participant is available and 
agrees to join the talk session, the server application 114 
causes his client application/browser 166/168 to display the 
message and gives him an opportunity to respond. 

If the user elects to respond, he enters a message in a 
response input box and causes th& appropriate browser 168 
to send the information defined therein to the server appli- 
cation 114. The response input box is very similar to the talk 
session dialog input screen 800, shown in FIG. 8 and is 
therefore not described herein. Upon receiving the response, 
the server application 114 resends the first participant (e.g., 
Arlene) a dialog screen showing the second participant's 
response alongside the first participant's initial message. 
From this screen the first participant has the opportunity to 25 
send a reply back to the second participant. An exemplary 
talk dialog screen 820 for Arlene is shown in FIG. SB. This 
screen shows in its upper section 822 Arlene 's initial mes- 
sage 824 and Mit's response 826. The screen 820 also 
includes a response input box 830 in which Arlene can enter 30 
a subsequent response. The talk session can proceed with 
screens like the screen 820 until one of the users signals an 
intention to exit the talk mode. 

As an example of the integration provided by the present 
invention, the server application 114 causes a incoming 35 
message alert to pop up during talk mode to notify a talk 
mode participant that he has a waiting communication board 
message. The alerted user can choose to check the message 
or CANCEL the alert, causing the server application 114 to 
initiate message processing operations already described in 40 
reference to FIGS. 4-6. While the user is checking his 
messages, the server application 114 causes the browser 168 
used by the other talk session participant to display a talk 
session paused message. The talk session is re -activated 
when the participant checking his messages chooses to 45 
rejoin the talk session. 

Talk session information is centrally maintained — in this 
case in a talk table 850 (stored in the database 108), Unlike 
most other modes (except for whisper mode), talk messages 
are not logged on the hard disk 104 server; therefore, the talk 50 
table 850 only includes a small set of status information for 
each talk session. In a preferred embodiment this status 
information includes: 



TalkSessID Unique key for each talk sessioQ generated by the 
server 

FirstParticipant First participant user name 
ScndParticipant Second participant user name; 

InActive Set to indicate that one of participants has not yet agreed 

to join session; 

MessageFlg Set to indicate that one of the participants has paused 

session to check a new message; 
McssagcTS Date and time when participant paused session to check 

new message. 



60 



application 114 to keep track of individual responses as talk 
sessions are not logged in the preferred embodiment. 

Another mode offered by the present invention is mail 
mode. Unlike conventional e-mail programs, in its mail 
mode the present invention is able to provide threaded mail 
over the Internet. An example of a mail screen 900 displayed 
for a particular user is shown in FIG. 9. 

The mail screen 900 lists mail received 902 and sent 904 
by a particular user (e.g., Mit). Each incoming e-mail 
message is treated by the server application 114 as a level 
one message that begins a respective e-mail thread. Replies 
to the incoming e-mail messages are indented on the mail 
screen 900, visually indicating their position as second level 
messages in their associated thread. For example, the incom- 
ing e-mail messages 906, 908 and 910 all have replies 906a, 
908i>, 910c. 

Each of the incoming messages has a subject line (e.g., the 
subject 912 of the message 906) that is underlined. When a 
user selects the underlined subject line he prompts the server 
application 114 to return to the user's chent application/ 
browser 166/168 an e-mail reply box with most fields (such 
as sender, recipient, subject, date and time) already filled-in. 
The user then fiUs in the message text and sends the e-mail 
message. As with the other modes, after a reply is sent the 
mail screen 902 is immediately updated by the server 
application U4 with the threading information. Outgoing 
mail is handled in the same manner except for the problem 
that threading information may not be maintained by exter- 
nal e-mail servers that receive the outgoing messages. 

As with the other system modes, e-mail information is 
centrally maintained — ^in this case in a mail table 920 (stored 
in the database 108) whose fields include: 



MaillD 

MaiJTlmcStamp 

Sender 

SenderAdr 

Recipient 

RecipientAdr 

Threadld 

ThreadLevel 

Subject 
MsgFN 



Unique key for each email message geiKraled by the 
server; 

Date and time message was sent or received; 

Sender Name; 

Sender e-mail address; 

Recipient Name; 

Recipient e-mail address; 

Unique Id for each mail Thread; 

Top level messages have level - 3, 

Replies have level = 2; 

Message subject; and 

Name of file on hard disk 104 where MsgText is 
stored 



The server application 114 allocates a single talk record 
for each new talk session. There is no need for the server 



The server application 114 allocates a mail message 
record for each new e-mail (outgoing, incoming, or reply) 
and updates these e-mail fields in much the same way as in 
the message situation described above. As a result, the 
processing of e-mail messages by the present invention is 
not further described. 

While the present invention has been described with 
reference to a few specific embodiments, the description is 
illustrative of the invention and is not to be construed as 
limiting the invention. Various modifications may occur to 
those skilled in the art without departing from the true spirit 
and scope of the invention as defined by the appended 
claims. 

What is claimed is: 

1. A system for threaded messaging of a message repre- 
sentation between participants including a sender and at 
least one recipient using a network of computers, compris- 
ing: 

a memory configured to store a message table and a 

plurality of messages; 
the message table including threading information for 

each message comprising parent, child, thread level and 

thread ID fields; 
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each message including respective threading information 
and a plurality of participants; and 

a delivery structure configured to deliver a representation 
of the message to the designated recipients, the delivery 
stmcture ftirther configured to instantly display the 5 
representations in an open formal wherein the delivery 
stmcture is configured to display the representations on 
a private message board that only shows communica- 
tions sent to and by the recipient and which can be 
viewed only by the recipient, and wherein the messages jq 
do not need to be selected to be read by dynamically 
generating HTML representations of the messages. 

2. The system of d aim 1, wherein the delivery structure 
is configured to enable a recipient to acknowledge messages; 
such that, when the recipient acknowledges a particular 
message, the delivery structure notifies a sender of the 
recipient's acknowledgment of the particular message. 

3. The system of claim 2, wherein the acknowledgment 
can be explicit or implicit, such that: 

when the acknowledgment is explicit, the system closes a 20 
thread including the particular message; and 

when the acknowledgment is implicit, the system leaves 
open the thread including the particular message, the 
implicit acknowledgment occurring whenever a par- 
ticipant replies to the particxilar message. 25 

4. The system of claim 3, wherein the explicit acknowl- 
edgment is employed by the participant to manifest accep- 
tance o^agreement to contents of the message. 

5. The system of claim 1, further comprising a server 
computer and a server mechanism executable in the server, 30 
the message table further comprising message records, each 

of which is associated with an owner, a subject, the sender 

and the recipient; 

such that, whenever the sender sends a message to N other 
recipients the server mechanism allocates 2xN message 35 
records, N of which have respective ones of the recipi- 
ents as the owner and the other N of which have the 
sender as the owner, all of the 2xN messages having the 
same sender and subject, respective pairs of the 2xN 
messages listing as the recipient a respective one of the 40 
recipients; 

the display strucmre being additionally configured to 
display for each of the N+1 participants only those 
message for which he is owner. 

6. The system of claim 5, wherein the server mechanism 45 
enables each of the participants to manipulate only those 
messages for which he is the owner 

7. The system of claim 6, wherein messages with the same 
subject, sender, recipient and message text are displayed 
nearly simultaneously to the respective owners of the mes- 50 
sages. 

8. The system of claim 1 further comprising a server 
computer and a server mechanism executable in the server, 
wherein the server mechanism is configured to queue at the 
server at least a subset of the messages addressed to the 55 
recipient without displaying to the recipient the representa- 
tions of the subset until the recipient has approved trans- 
mission of at least one of the messages in the subset, after 
which the server mechanism displays the representations of 
the subset to the recipient user. 60 

9. The system of claim 1, wherein the display structure 
displays the representation of the message along with a 
hyperlink field, the selection of which by the recipient 
causes the display structure to display to the recipient a reply 
window with at least some fields filled out with information 65 
associated v^th the hypertext field, enabling the recipient to 
formulate a reply to the sender of the message. 



10. The system of claim 1, wherein the memory is 
configured to maintain a plurality of private message boards, 
such that, whenever a representation of the message is 
displayed on the private message board of one participant in 
the message, a corresponding representation of the message 
is displayed nearly simultaneously on the private message 
board of another participant in the message. 

11. A communication board system for use in a computer 
network including a server, comprising: 

a server application executable on the server; and 

a client application providing an interface between system 
users and the server application; 

such that said cHent application and server apphcation are 
configured cooperatively to provide each of said users 
with a respective view of a virtual bulletin board 
system illustrating history and content of at least a 
subset of messages, said respective view being acces- 
sible to and customizable for a corresponding one of 
said users, wherein each message including respective 
threading information and the history includes inden- 
tations of the content indicating a respective position of 
the content within the history; and 

wherein said respective view includes only those of said 
messages associated with conversations to which said 
corresponding user is a participant, and wherein the 
respective views display representations of the mes- 
sages in an open format in which the content of the 
messages can be read without selecting the messages, 
by dynamically generating HTML representations of 
the messages. 

12. The communication board system of claim 11, further 
comprising: 

a data repository in which the server application stores 
information about system users and messages 
exchanged between said users. 

13. The communication board system of claim 12, 
wherein the data repository comprises: 

a message table including message records, each of which 
is associated with a message having a sender, recipient, 
owner, subject and thread id; 

such that, whenever a user sends a message to N other 
users, the server application allocates a message family 
of 2xN message records, N of which have respective 
ones of the other users as the owner and the other N of 
which have the first user as the owner, all of the 2xN 
messages having the same sender, subject and thread id, 
respective pairs of the 2xN messages listing as the 
recipient a respective one of the other users, the sending 
user and other users being thread participants. 

14. The communication board system of claim 13, 
wherein, when a first user sends a first level message to a 
second set of users using the client application, the server 
application is configm-ed in response to: 

allocate the family (first level family) of message records 

for the first level message; 
generate a unique thread id and associate the unique 

thread id with each of the first level family; 
update each member of the first level family with the 

sender, recipient, owner and subject information for a 

respective thread participant; 
issue a message alert to the client apptications of each of 

the other users; 
transmit a representation of a respective message record 

to the client application of each of the second set of 

users who agrees to delivery of the message; and 
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hold in abeyance transmission of a represenlalion of a 
respective message record to each of the second set of 
users who does not agree to delivery of the message. 

15. The system of claim 14, wherein, when an additional 
user sends a reply to a message from another user using the 5 
client appUcation, the server application is configured in 
response to: 

allocate the family (reply family) of message reconds for 
the reply message; 

associate the unique thread id from a parent family with 
each member of the reply family, the parent family 
being the message records associated with the message 
from the another user; 

update each member of the reply family with the sender, 
recipient, owner and subject information for a respec- 
tive participant in the reply message; 

link members of the reply family with related message 
records of the parent family; and 

transmit a representation of a respective reply message 20 
record to the client application of the another user. 

16. The communication system of claim 15, wherein, 
when the additional user exphcitly acknowledges an incom- 
ing message using the client application, the server appli- 
cation is configured in response to: 25 

update the message records associated with the thread that 
includes the incoming message to show that the thread 
is closed, and append each response; 

transmit a representation of the incoming message to the 
client applications of participants in the thread that 
includes the incoming message conveying that the 
thread is closed. 

17. The communication system of claim 15, wherein, 
when a third user implicitly acknowledges an incoming 
message using the client application, the server application ■^^ 
is configured in response to: 

update the message records associated with the thread that 
includes the incoming message to show that the thread 
is responded to; 

40 

transmit a representation of the incoming message to the 
client applications of participants in the thread that 
includes the incoming message conveying that the 
thread is responded to. 

18. The communication board system of claim 11, 
wherein the respective views display the representation of a 
message along with a hyperhnk field, the selection of which 
by the user causes the server and client applications coop- 
eratively to display to the user a reply window with at least 
some fields filled out with information associated with the 
hypertext field, enabling the user to formulate a reply to the 
message. 

19. The commimication board system of claim 11, 
wherein messages with identical subject, sender, recipient 
and thread id can be provided nearly simultaneously on the 
respective views provided to the respective owners of the 
messages. 

20. The communication board system of claim 11, 
wherein the server application and the cUeni application are 
browser-based, enabling the communication board system to 
be implemented on any computer network compatible with 
Internet-based protocols. 

21. The communication board system of claim 20, 
wherein the computer network is selected from: 

the Internet; 
an intranet; or 
an extranet. 
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22. A system for open display bulletin boards for use by 
a plurality of participants in a network of computers, com- 
prising: 

a computer configured to provide a bulletin board system 
a memory configured to store a plurafity of messages; 
the messages include threading information for each 

message comprising parent, child, thread level and 

thread ID fields; 
the messages include a plurality of participants; 
the participants include a sender and at least one recipient; 

and 

a delivery structure configured to deliver the messages, 
the delivery structure further configured to instandy 
display the representations in an open format wherein 
the computer is configured to display the messages on 
a pluraUty of private message boards, each of which 
only shows communications sent to and by a respective 
participant and which can be viewed only by the 
respective participant, and wherein the messages do not 
need to be selected to be read by dynamically gener- 
ating HTML representations of the messages. 

23. The system of claim 22, wherein the computer is 
configured to enable recipients to acknowledge messages; 
such that, when the recipient acknowledges a particular 
message, the computer notifies a second participant in the 
particular message of the recipient's acknowledgment of the 
particular message, and wherein the system includes a 
safeguard to prevent deletion of the messages without 
acknowledgment . 

24. The system of claim 23, wherein the acknowledgment 
can be explicit or implicit, such that: 

when the acknowledgment is explicit, the computer closes 
a thread including the particular message; and 

when the acknowledgment is implicit, the computer 
leaves open the thread including the particular 
message, the implicit acknowledgment occurring 
whenever the recipient replies to the particular mes- 
sage. 

25. The system of claim 24, wherein the explicit acknowl- 
edgment is employed by the recipient to manifest acceptance 
o&'agreement to contents of the particular message. 

26. The system of claim 22, fiirther comprising: 

a message table including message records, each of which 
is associated with a message having a sender, recipient, 
owner and subject; 

such that, whenever the sender sends a message to N 
recipients, the computer allocates 2xN message 
records, N of which have respective ones of the recipi- 
ents as the owner and the other N of which have the 
sender as the owner, all of the 2xN messages having the 
same sender and subject, respective pairs of the 2xN 
messages listing as the recipient a respective one of the 
other participants; 

the computer being additionally configured to display for 
each of the N+1 participants only those message for 
which he is owner. 

27. The system of claim 26, wherein the server mecha- 
nism enables each of the users to manipulate only messages 
of which he is the owner. 

28. The system of claim 27, wherein messages with the 
same subject, sender, recipient and message text are dis- 
played nearly simultaneously to the respective owners of the 
messages. 

29. The system of .claim 22, wherein, whenever a first 
representation of a particular message is displayed on the 
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private message board of one participant in the particular 
message, a corresponding representation of the particular 
message is displayed nearly simultaneously on the private 
message board of another participant in the particular mes- 
sage. 5 

30. The system of claim 22, further comprising a server 
computer and a server mechanism executable in the server 
wherein the server mechanism is configured to queue at the 
server at least a subset of the messages addressed to the 
recipient without displaying the representations of the subset lo 
until the recipient has approved transmission, after which 
the server mechanism displays the representations of the 
subset to the recipient. 

31. The system of claim 22, wherein the computer dis- 
plays the representation of the message along with a hyper- 15 
link field, the selection of which by the recipient causes the 
computer to display to the recipient a reply window with at 
least some fields filled out with information associated with 
the hypertext field, enabling the recipient to formulate a 
reply to the sender of the message. 20 

32. A private message board system for use in a network 
of computers including a server computer, comprising: 

a server mechanism executable in the server, the server 
mechanism configured to: 

provide a plurality of private bulletin boards for each of 25 
a plurality of users of the systena, wherein each of 
said private bulletin boards shows history of mes- 
sages associated with conversations involving a 
respective user, wherein each message including 
respective threading information and the history 
includes indentations that delineate a message's 
place within the history; and 

display representations of the messages in an open 
format that only shows communications sent to and 
by the respective user, and wherein by dynamically 
generating HTML representations of the messages, 
the messages do not need to be selected to be read. 

33. The system of claim 32, wherein the server mecha- 
nism is configured to enable users to acknowledge mes- 
sages; such that, when the user acknowledges a particular ^ 
message, the server mechanism notifies a second user who 

is a participant in a thread containing the thread of the user's 
acknowledgment of the particular message. 

34. The system of claim 33, wherein the acknowledgment 
can be explicit or implicit, such that: ^5 

when the acknowledgment is explicit, the server mecha- 
nism closes the thread including the particular message; 
and 

when the acknowledgement is implicit, the server mecha- 
nism leaves open the thread including the particular 
message, the implicit acknowledgement occurring 
whenever the user replies to the particular message. 

35. The system of claim 32, further comprising: 

a message table including message records, each of which 55 
is associated with a message having a sender, recipient, 
owner and subject; 

such that, whenever the user sends a message to N other 
users, the server mechanism allocates 2xN message 
records, N of which have respective ones of the other 60 
users as the owner and the other N of which have the 
user as the owner, all of the 2xN messages having the 
same sender and subject, respective pairs of the 2xN 
messages listing as the recipient a respective one of the 
other users. 65 

36. The system of claim 35, wherein messages with the 
same subject, sender, recipient and message text are dis- 



played nearly simultaneously on the private message boards 
of the respective owners of the messages. 

37. The system of claim 32, wherein the server mecha- 
nism is configured to display nearly simultaneously with its 
posting a particular message on the private message boards 
of all participants in the message. 

38. The system of claim 24, wherein the server mecha- 
nism is configured to queue at the server at least a subset of 
the messages addressed to the user without displaying the 
representations of the subset until the user has approved 
transmission, after which the server mechanism displays the 
representations of the subset to the user. 

39. The system of claim 24, wherein the server mecha- 
nism displays a representation of the message along with a 
hyperlink field, the selection of which by the user causes the 
server mechanism to display to the user a reply window with 
at least some fields filled out with information associated 
with the hypertext field, enabling the user to formulate a 
reply to the sender of the message. 

40. A method for threaded instant messaging for use in a 
computer network, comprising the steps of: 

maintain threading information of said messages com- 
prising parent, child, thread level and thread ID fields; 

displaying a representation of said threading information 
along with said messages; 

displaying messages sent over the network involving a 
user of the network so that only said user can view 
messages sent and received by said user; 

displaying said messages in an open format so that 
content of said messages is viewable without selection; 

immediately making said messages available for viewing 
by said user whenever said user is online by dynami- 
cally generating HTML representations of the mes- 
sages; 

whenever a user sends a message to N other users, 
allocating a message family of 2xN message records, N 
of which have respective ones of the other users as the 
owner and the other N of which have the first user as 
the owner, all of the 2xN messages having the same 
sender, subject and thread id, respective pairs of the 
2xN messages listing as the recipient a respective one 
of the other users, the sending user and other users 
being thread participants; and 

when a first user sends a first level message to a second 
set of users: 

allocating the family (first level family) of message 

records for the first level message; 
generating a unique thread id and associate the unique 

thread id with each of the first level family; 
updating each member of the first level family with the 

sender, recipient, owner and subject information for 

a respective thread participant; 
issuing a message alert to each of the other users; 
transmitting a representation of a respective message 

record to each of the second set of users who agrees 

to delivery of the message; and 
holding in abeyance transmission of a representation of 

a respective message record to each of the second set 

of users who does not agree to delivery of the 

message. 

41. The method of claim 40, further comprising the steps 
of: 

when an additional user sends a reply to a message from 
another user, 

allocating the family (reply family) of message records 
for the reply message; 
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associating the unique thread id from a parent family with 
each member of the reply family, the parent family 
being the message records associated with the message 
from the another user; 

updating each member of the reply family with the sender, ^ 
recipient, owner and subject information for a respec- 
tive participant in the reply message; 

linking members of the reply family with related message 
records of the parent family; and 

transmitting a representation of a respective reply mes- 
sage record to the another user. 

42. The method of claim 41, further comprising the steps 



of; 



when the additional user explicitly acknowledges an ^5 
incoming message, 

updating the message records associated with the thread 
that includes the incoming message to show that the 
thread is closed, and appending each response; and 

transmitting a representation of the incoming message to 20 
participants in the thread that includes the incoming 
message conveying that the thread is closed, 

43. The method of claim 41, further comprising the steps 
of: 

when the additional user implicitly acknowledges an 

incoming message, 
updating the message records associated with the thread 

that includes the incoming message to show that the 

thread is responded to, and appending each response; 

and 

transmitting a representation of the incoming message to 
the client applications of participants in tbe thread that 
includes the incoming message conveying that the 
thread is responded to. 35 

44. A system for threaded messaging of a message rep- 
resentation between participants including a sender and at 
least one recipient using a network of computers, compris- 
ing: 

a memory configured to store a message table and a 40 
plurality of messages; 

the message table including threading information for 
each message comprising parent, child, thread level and 
thread ID fields; 

each message including reactive threading information 
and a plurality of participants; 

a delivery structure configured to deliver a representation 
of the message to the designated recipients, the delivery 
structure further configured to instantly display the 
representations in an open format wherein the messages 
do not need to be selected to be read by dynamically 
generating HTML representations of the messages; and 



a server computer and a server mechanism executable in 
the server, the message table further comprising mes- 
sage records, each of which is associated with an 
owner, a subject, the sender and the recipient; 

such that, whenever tbe sender sends a message to N other 
recipients the server mechanism allocates 2xN message 
records, N of which have respective ones of the recipi- 
ents as the owner and the other N of which have the 
sender as the owner, all of the 2xN messages having the 
same sender and subject, respective pairs of the 2xN 
messages listing as the recipient a respective one of the 
recipients; and 

the display structure being additionally configured to 
display for each of the N+1 participants only those 
message for which he is owner, and wherein the server 
mechanism enables each of the participants to manipu- 
late only those messages for which he is the owner. 

45. A system for open display bulletin boards for use by 
a plurality of participants in a network of computers, com- 
prising: 

a computer configured to provide a bulletin board system 

a memory configured to store a plurality of messages; 

the messages include threading information for each 
message comprising parent, child, thread level and 
thread ID fields; 

the messages include a plurality of participants; 

the participants include a sender and at least one recipient; 

a delivery structure configured to deliver the messages, 
the delivery strucmre further configured to instantly 
display the representations in an open format wherein 
the messages do not need to be selected to be read by 
dynamically generating HTML representations of the 
messages; and 

a message table including message records, each of which 
is associated with a message having a sender, recipient, 
owner and subject; 

such that, whenever the sender sends a message to N 
recipients, the computer allocates 2xN message 
records, N of which have respective ones of the recipi- 
ents as the owner and the other N of which have the 
sender as the owner, all of the 2xN messages having the 
same sender and subject, respective pairs of the 2xN 
messages listing as the recipient a respective one of the 
other participants; 

the computer being additionally configured to display for 
each of the N+1 participants only those message for 
which he is owner, and wherein the computer enables 
each of the participants to manipulate only messages of 
which be is the owner. 
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